All DatabasesMacTech Vol 04-1988
Devices
Volume Number: 4
Issue Number: 3
Column Tag: Macintosh II
Graphics Devices & Chroma
By Greg Marriott, The MacHax™ Group
The Good(?) Old Days
How many of you Mac programmers out there remember how hard it was to
master Quickdraw? Come on, raise your hands... Now, how many of you still have
trouble sometimes? (Yes, my hand is up, too!) Remember those long hours spent
trying to figure out how SetOrigin works, and wondering which regions stick to the
window and which ones stick to the GrafPort coordinates? Wasn’t it a bummer trying
to remember why FrameRgn and FramePoly produce different results? I can see you
grimacing as you recall the many hours spent wondering where your pictures go when
you offset them. I, for one, refused to knuckle under, and finally managed to get most
of it figured out. From the abundance of Mac software out there, it looks like a lot of
other people persevered as well.
Apple Consults Ted Turner (or Color, Anyone?)
Just when we had everything under control, along came Color Quickdraw! With it
came several new concepts to absorb. The most obvious addition to the Mac’s graphics
system is, of course, color. Obvious, that is, to all those lucky enough to have a color
monitor attached. People with monochrome screens have to settle for lots of shades of
gray. Really lucky people can have monochrome screens and color screens hooked up at
the same time! This is where I (very smoothly) slide into a discussion of another
addition to the Quickdraw system: the ability to have several display devices instead of
a lone monitor. The phrase “display device” could apply to a wide variety of
equipment, but I’ll limit my discussion to the CRTs we’ve come to know and love. (For
a description of how the color part of Color Quickdraw works, read Inside Macintosh
Vol. 5, and take a look at Steven Sheets’ article in the September ’87 MacTutor).
Six of One, Half a Dozen of the Other
As most of you know, the Mac II has expansion slots (for you trivia buffs out
there, it has six of them). Each of these slots can have something really neat plugged
into it, like additional processors, data acquisition boards, and other stuff like that.
But, if you don’t have a video card and monitor plugged in, you won’t be able to see
what’s going on. I ought to know. My monitor took about a month longer to arrive than
my CPU did. The Mac made a nice sound when I turned it on, but that got really boring
after the first couple of hundred times. Anyway, with six slots available, enterprising
(and loaded) people can plug in six video cards to use with many monitors of various
shapes and sizes (some cards allow more than one monitor to be attached).
So, with lots of screens putting quite a load on your table (not to mention your
budget), what would you expect to see? Several identical copies of your desktop?
Sounds interesting, but not very practical. Quickdraw treats all the video devices
collectively as a single, possibly irregular, display. Windows may be placed anywhere
on the desktop, and as a result a single window can extend across several monitors. The
effect is e specially impressive when adjacent monitors have different color
environments, or one is color and the other b/w. This spectacular feat is accomplished
through careful management of graphics devices.
Graphics Devices can be (loosely) described as anything Color Quickdraw can
draw into (I’ll refer to Color QuickDraw as CQD from here on out). By the way, when I
mention a graphics device I’m not talking about the piece of expensive hardware sitting
on your desk. I’m referring to the data structure CQD uses to describe the piece of
expensive hardware. A GDevice record holds information about the device’s postition
in Quickdraw space, the color capabilities, color matching routines, and cursor
handling on the device. Physical devices also have drivers associated with them,
identified by the gdRefNum field, to handle things like changing the depth or color
environment. For multiple screens, CQD maintains a linked list of GDevices (actually,
it’s a list of handles to GDevices), one for each monitor. The head of the list is in a low
memory global called DeviceList. The screen with the menu bar is described by the
GDevice in MainDevice, also in low memory. When drawing is happening on a device, a
handle to it is stored in theGDevice.
Normally, applications should ignore the fact that their windows might extend
over more than one screen and let Quickdraw take care of the details. As a matter of
fact, programs should never (well, almost never) depend on any particular device
configuration, such as the number of colors present. The user can change the
environment any time he wants to, one way being through the Control Panel.
Sometimes, though, taking advantage of the way graphics devices work can be
useful. I’ve written a desk accessory to help illustrate some points to keep in mind
when dealing with graphics devices. I’m not going to go over everything you should
know about graphics devices here, since Inside Macintosh, Vol. 5 covers them very
well.
What a Great Name For a Color DA!
Chroma is a desk accessory that displays all the colors (or gray shades)
currently available on attached graphics devices. It pays attention to the depth (bits
per pixel) of each device when deciding how many colors to draw. Other useful data are
also displayed, such as the slot number a device is plugged into, the refNum of the
driver, the GDevice flags, and the device’s mode. The flags indicate the presence of
several conditions, including whether or not the device is the main screen, was
initialized from RAM, was initialized from a ‘scrn’ resource, is the active screen, has
a driver, and is color or b/w. The mode is the number passed to the driver, if there is
one, to set the pixel depth, etc.
When the Chroma window lays across more than one device, the piece of the
window on a device reflects that device’s environment. That is, a color monitor with
256 colors and a b/w monitor with 16 gray shades would cause Chroma to draw part of
the window with lots of little color squares and the other part of the window with big
gray ones. The rest of the information provided is also pertinent to the device on which
it is drawn. By positioning the slot number on the boundary between screens, you’ll
see part of a different number on each screen. Chroma starts with a rather small
window, so you can leave it around to examine your color environment and not cover up
other areas of interest. It supports zooming, though, so you can get a better look at the
colors of a device. Chroma’s window zooms to fill the screen where the zoom box was
when you hit it. (To learn about DA programming in general, see some past issues of
MacTutor [Ed, how about suggesting some articles here?]).
A Self-Aware(!) Machine
Since Chroma’s activities take place in (potentially) color environments, it
needs a color window. But, color windows can only be created in the presence of CQD.
So, the first thing Chroma does when it’s opened is to make sure CQD is present. Some
programs check this by looking at a low-memory global called ROM85 and seeing if
they are on a Mac II. It’s true that CQD only runs on a Mac II, but that may not always
be the case (we might see a color MacSE, but then again, that’s just a silly rumor...
right?). A much more portable way to detect CQD is by calling SysEnvirons. The
SysEnvirons call fills in a record describing the computer’s configuration.
SysEnvirons notes the presence of CQD, a floating-point coprocessor, and the system
version, among other things. For a detailed explanation of SysEnvirons, see Apple
TechNote #129.
If Chroma is opened on a machine without CQD, it puts up a “regular” window
instead of a color window, and draws a picture complaining about the lack of color
Referenced by (108):